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® videotex information utfllty. 



© An architecture is disclosed for the implenr^entation of an infomnation utility for accessing information and 

executing transactions on an interactive basis between Videotex databases and individual end user terminals, 
f^some or all of which may be remotely located with re^>ect to each ottier. The utility may be associated with a 
^Videotex Application Network (VAN) and includes a combination of distributed, semiautonomous Operations 

Nodes (ONs), each characterized by 1) one or more affiliated users. 2) the inclusion of some form of database^ 
fS^«id 3) one or more customized application programs, and each Is also capable of "standalone'' operation. A 
<Otypical ON with end-user tenminaJs, which may be referred to as an Establishment Operations Node (EON), 

supports a unique user interface through which users get contt^olled and secure access to a wide variety of 
1^ databases stored locally and/or remotely. Through this node, users may also interact with a large number of 
^application programs distributed over the entire VAN which provide additional and specialized services. The user 
^interface, the mechanisms for secure access to information, and the application environment supported by the 

ON are important features of the invention and ONs may be adapted to special functions within the network. For 
gj example, while a typical node may consist of a system with one or more databases and end user temiinals ■ 

(EON), another node may consist only of speciaUzed databases (DON) maintained by infomnation providers - 

(IPs) without end users or application programs. Similarly, a third node may merely consist of a directory 
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database with a number of unrelated end user terminals (TON), Anotiier node may be configured with a directory 
database and just a s&i of application programs providing services to users on the network (PON). A number of 
small in-house users may cooperate to form a muKlorganization node (MOON) and special nodes may be 
formed to handie access to other networks (NON) or to interface wi^ third party databases (ION). Rnally, a node 
may assume the role of a Systems Operations Node (SON) which maintains a global directory of databases and 
application programs available at various nodes and may act to supervise and coordinate the interactions and 
operations of all the nodes in the system. In all, the application architecture and specific implementation 
disclosed offer valuable capabilities and services to end users. 
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Videotex tnfppfirtlOTUMIIte 



Background of the Invention 

The present invention relates to electronic Information and communication systems and more particu- 
5 iariy to a combination of operaSonal nodes incorporating datat>ases and application programs for providing 
graphic3[ and textual information (Videotex) and transactional capabilities to end-user tenminais connected 
thereto. 

A Videotex service is a medium for conveying infonnation electronically in an effective, user friendly, 
and relatively inexpensive manner to a large user population, ft combines color, graphics and text in a 

TO single display to provide an attractive presentation of infomnation to experienced as welt as novice users. It 
is assumed that as its popularity increases the majority of users, while not being trained in data processing, 
will be interested In using it for m^sage exchange and transactional activities, in addition to using it to 
access a wide range of Information bases. Experienced users will generally wish to obtain specific 
information in a quick and direct fashion while novice usens will tend to browse through dataisases trying to 

15 determine the value of the information being offered. 

First and second generation Videotex services have tended to be limited both in the range of 
information bases offered and in the ability of the system to cater to the capabilities of a wide range of end- 
users. 

On fhe ottier hand, Data Processing Networks, such as the IBM VNET and tfie XEROX ETHERNET. 
20 have been developed to improve and integrate communication between and among individual computer 
terminals and databases. However, these networks essentially are either in-house, kx:al area systems 
wherein the majority of the operating devrces, work stations and data bases are proximately disposed, such 
as within an office or a plant, or are non-interactive and provide for a file ti-ansfer mode of operation. 

Other networks such as ttie IBM Infonmation Network (*N) and IBM's PVM systems do provide on-line 
26 interactive ses^ons between centralized data processing machines and their users who may be located 
remotely- However, these networks do not offer the consistent and easy-to-use interfaces for which Vkjeotex 
services are well known. 

Witt the increasing growth in large, centralized special-purpose databases along with integrated 
individual compact work stations capable of handling information presentations in cotor, graphics, and text - 
3Q (Videotex), the desirability of developing an extended architecture to foster cooperation among a wide range 
of remotely located temninals databases has become manifest* 



Summary of the Invention 

The present Invention involves an architecture for and the implementation of an infomrtation utility for 
accessing information and executing transactions on ^ interactive basis between Videotex databases and 
individual end user tenfninais. some or all of which may be remotely kx^ted with respect to each otiier. A 
Videotex Application Network (VAN) toward whidi the invention is directed includes a combination of 

40 distributed, semlautonomous Operations Nodes (ONs), each characterized by 1) one or more affiliated 
users, 2) the inclusion of some form of database, and 3) one or more customized application programs. 
Each node is ^so capable of *stand alone" oper^n, that is, it can service the needs of its user population 
and need not be connected to any other node. 

A typical Operations Node witii end-user tenminais, which may be refen^ed to as an Establishment 

46 Operations Node (EON)» supports a unique user interface through which users get contix^iIed and secure 
access to a wide variety of databases stored iocaily and/or remotely. Through tiiis node, users may also 
interact with a large number of application programs distributed over the entire VAN which provide 
additbnal and specialized services to users of the node; The user interface, the mechanisms for secure 
access to information, and tiie applicatiCHi environment supported by the ON are important features of the 

so invention. 

Provision is made for Operations Nodes to be adapted to special functions within tfie networic. For 
example, while a typical node may consist of a system witin one or more databases and end user terminals 
(EON), another node may consist only of specialized databases (DON) maintained by information providers 
(IPs) without OTd users or application programs. Similarly, a thinj node may merdy consist of a directory 
datat)ase with a number of unrelated end user tenninals (TON). An operations node may be configured with 
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a directory database and just a set of application programs providing services to users on the network * 
(PON), A number of smaJI in-house users may cooperate to forni a multiorganization node (MOON) and 
special nodes may be formed to liandle access to other networks (NON) or to interface with third party 
databases (ION). Finally, an Operations Node may assume the role of a Systems Operations Node (SON) 
5 which maintains a global directory of databases and application programs avail^le at vaiious nodes and 
may act to supervise and coordinate the interactions and operations of all the nodes in the system. In all, 
the application architecture and specific Implementation disclosed offer valuable capabilities and services to 
end users. 

10 

Brief Description of tiie Drawings 

Fig.1 illustrates a Videotex Application Network (VAN) in which the present invention may be 
implemented and various configurations that an Operations Node may assume. 
7B Fig. 2 shows the overall architecture of an Operations Node (ON) In accordance with the present 

invention. 

Fig. 3 is an example of a hardware and software configuration for an ON host. 
Fig. 4 shows the relationship of ON-spedfic software to other exemplary components that may exist 
on an ON host. 

20 Fig. 5 illustrates the global data structure in an ON host. 

Rg. 6 is an overview of a Transaction Application Subsystem (TAS). 

Rg. 7 is an outiine of a sample application program running under TAS. 

Rg. 8 Is an overview of the transaction data area maintained by an ON host, 

Rg. 9 details the logic involved in starting an application program on the host. 
35 Frg. 10 is an example of the hardware Involved in implementing the distribution subsystem. 

Rg. 11 shows tiie software involved in executing the logic of tiie distribution subsystem. 

Rg, 12 is an example of a typical end user terminal configuration tiiat may be connected to an ON 
distribution subsystem. 

Fig- 13 shows the software involved in executing the logic of the end user temninaL 
so Fig. 14 provides details of tiie Input/Output Control System on the end user terminal. 

Rg. 15 shows how kaysti^es input by end users are processed by tiie temninal software. 



Detailed Description of the Invention 

35 

A system generally embodying the main components of the present invention connected to a Videotex 
Appli cation Network (VAN) is Illustrated in Figure 1. A fundamental component in tiie architecture is the 
Operations Node (ON), which is the unit tiirough which all end-user terminals are connected to the system 
and wherein resides one or more databases witii Videotex information avafiable to otiier connected nodes. 

40 The nodes in their various fbrmSt th^r Interactions with end users and their services together make up an 
information utility or system. 

Rrst con^dering the system conceptually, all of the nodes, innespective of tiielr particular forms, are 
semlautonomous in tiiat they are capable of many functions and operations on their own, that is, they may 
carry out in-house data processing and information exchange between their local datat>ases and terminals 

45 without Interacting witii tiie system at large. The Operations Nodes are also distributed, that is, remotely 
boated witii respect to each other, and each may be connected to one or more other nodes in tiie system. 
The communications paths also support multiple concurrent "conversations" botii from and to any particular 
Operations Node as well as between any p^r of Operations Nodes* At the same time the paths are such 
that the addition or deletion of any one or more nodes causes a minimal amount of disruption to the 

50 network. 

The VAN does not support a "single system image", so that each ON will recognize (hold a user profile 
for) only that set of users with which it expects to be dealing on a regular basis. Each such profile Is 
Identified by an ON-unique identifier. The identifier takes tiie form of an rdentificatfon name, number, or 
symbol { the ON-ID ). concatenated with a System Access Code ( SAC ). The SAC/ON-ID combination ts 
56 unique within the VAN. A user for whom there is an identifiable profile on an Operations Node Is said to be 
affiliated witii that ON. A user may be permitted to be affiliated wtti more tiian one ON, Profile records of a 
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user at different ONs need not be identical; indeed^ for various reasons of security and economy, a user 
may have different profiles at different ONs. However, a user can be serviced only at ONs with which he is 
affiliated. Servicing includes the process of logging on to the system, information retrieval, and the conduct 
of various transactionaf functions (e.g., data collection), 
s Infonnation at an Operations Node is preferably organized in terms of oaaes . A page is a variable 
length data structure consisting of control information and dtsptayable data. Oisplayable data in a page Is 
normally encoded In accordance with the North American Presentation Level Protocol Syntax (NAPLPS). an 
industry standard, and preferably read out In color, graphics, and text form on a display device at the 
terminal of an end user. 

TO Pages may be organized as scroll sequences for purposes of continuity of presentation, animation 
effects or for other reasons. Such sequences are known as oaoesets . There is no conceptual Ifmitation on 
the number of pages comprising a pageset. A group of pagesets that are related by some semantics may 
be recognized l>y the system as belonging to a database . Each such dateibase is identified by a unique 
identifier In the form of an ON-ID concatenated with a Database Access Code (DAC). 

16 Databases may be owned by Information oroviders (IPs) who are responsible for tiieir creation and 
maintenance. An IP may be one p^son or may be an organization consisting of several people or entitles, 
each with one or more assigned roles. 

A VAN database Is sard to be to an Operations Node if its pages are permanently stored at that 
ON and are maintained by privileged users (IPs) affiliated wrth that ON. Similarly, If the pages of a database 

20 are stored elsewhere in the VAN. such a database would be viewed as being remotely situated . In either 
case it is preferred that all VAN datat>ases share a common well-defined structure, and the pages or 
pagesets of a particular database are always stored within and maintained by a single ON. 

One or more gxjl oaths may be defined for a page. These exit paths allow the user to navigate from the 
cun-ently displayed page to another page. Two types of exit paths are defined. The first type, user-defined 

25 exit patiis, are tiiose that are derived by the system from ttie user's prior behavior. For instance, an exit 
path to the previous page displayed is known to the system t>ecause it keeps track of a limited history of 
page accesses by the user. Other such exit paths are described more fully t»elow. The other type. 
Information Provider-defined exit patiis, are embedded in the control area of a page and are invoked by 
certain functions also described below. 

30 Users can request infbmnation from VAN databases and Third Party Databases (TPDs). Infomnation on 
TPDs may be organized differently from VAN databases, but access mechanisms for the two t^s of 
databases are adapted to be very similar. 

VAN databases, as mentioned, may be locally or remotely sltjated. However, because all such 
databases are structurally Identical, accesses to non-local as well as local Videotex databases are earned 

35 out In such a way that the user is unaware of the locality of the datai>ases. This is dor^ by keeping implicit 
both the process of connectif>g to a remote ON for access to a non-bcal database, and the process of 
disconnecting from it when the user signals a context charge. 

VAN datat>ases, whether kx;al or remote, that are accessible from a given ON. have entries in the 
database directory of that ON. This directory enables the ON to determine the location and type of the 

40 database in question. It is to l>e noted that not all VAN datat)ases are necessarily accessible from every ON 
In the network. The accessibility of a VAN database from a given ON will typically be a matter of negotiation 
between tfie ON wishing access and the database-owning IP. 

The procedures for handling accesses to TPDs. as mentioned p will be similar. An exit path from a local 
or remotely situated VAN datatDase page will indicate tiiat a page from a TPD is to be retrieved. Like VAN 

46 databases, TPDs are also represented by an entry in the ON's database directory. If the requested TPD Is 
accessible from the ON with which the user is affiliated, then an entry will have been set up in the ON's 
directory. This entry enables the ON to make requests to the (external) system on which the TPD Is 
resident. The TPD system, ^iie maintaining its databases independent of the VAN, will recognize the 
page, pageset and database semantics in order to carry out a meaningful access session with the VAN 

60 user. The particular manner in which communication between a TPD system and the VAN is conducted will 
vary and be within the purview of ttiose skilled in the art and so will not be discussed here in detail. 



End-User Functions 

A comprehensive repertoire of functions is avalabte to the end user to access information within tfie ON 
witti which he is affiliated as well as on other Of^. These are discussed in this section in the context of 
using a computer keytx»ard at the end user terminal to call up and control function operation and display. 
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A scroll function allows tiie end user to access pages In their sequence order within a pageset ITie 
user may scroK forward to aa^ess the next page in sequence or may scroll back to access the previous 
page. The point of reference In scrolling is always ttie currently displayed page. The exit paths associated 
with scrolling are always embedded in the control section of the cunrently displayed pagers data structure. 
5 A retrace function allows the end-user to trace bade (in time sequence) to pages previously displayed. 
The exit path for the retrace function is derived by the system based on past user actions, 

A menu selection function allows the end user to make a selection of an integer within a given range 
such that each such selection causes the system to undertake a potenti^ly different exit path. Each such 
exit path must be defined in the control section of the cunrently displayed page. The vanous types of exits 
10 for a selection are: 

Npil This path indicates that the selection is currently inactive and is therefore not a valid exit path. 

Direct Refereni;^ In this case, the exit identifies uniquely a page witiiin some database In some 
Operations Node within the VAN. 

IDescription t>ased search This exit provides a program identifier that is invoked by the system. The 
16 program coTKlucts a search of the cunrent database according to some search criteria and produces one or 
more pages containing the results of that search. The criteria may be provided by the end-user in the form 
of responses to prompt strings specified in the exit path. 

Program Trioaer This exit is a generalization of the description based search exit. Whereas the 
description based search exit provides for the activation of a special purpose program to search a VAN 
20 database, program triggers allow for the activation of any program. The logic of such programs may not be 
known to the system. 

Command String This exit allows for simuiatior> of other types of exits from within a menu selection. For 
example, this exit may t>e used to simulate the scroll function described above. 

It should be notad tiiat not all pages may have menu selection exits defined in their control sections. A 
25 page that has menu selection defined for it is known as an index page. 

A find function permits a page within a database to be accessed directly by a user. The find function 
requires the user to specify the database name, the pageset and page identifiers, A user session manager 
at each ON will maintain context (or present state) Information for every active user. The database context 
of a user is the database to which the currently displayed page belongs. Because the current database is 
30 always known to the system, a user need not specify tiie database name if he wishes to find a page within 
tiie current database. An IP intending to create a database for access by the VAN user community must 
specify a database name which is used by the session managing ON when accessing that database on 
behalf of a user. An IP may own more than one database witiiin an ON. 

A backup function is used to display the last IrKlex page prior to display of ttie currently displayed 
35 page. Successive backups work backwards through a (limited) sequence of previously seen Indexes* 

A next function is used to take the next exit path on the last index page displayed prior to the display of 
the currentiy displayed page, ft is equivalent to a backup followed by an increment of the choice number, 
saving the intermediate display, its prime use is for browsing through a list of Items. 

A mark ftinction causes tiie system to "remember" tiie currentiy displayed page for later access via a 
40 recall function. 

A recall function Is used to display tiie page that was •'marked". If several pages are marked before a 
recall is issued, the most recentiy mariced page will be displayed. Context information is saved with the 
mark and restored with recalir so that if the end user has reti'ieved a page via menu choice, matlced rt, and 
later recalled it tiie backup function would return to tiie menu from whldi tiie end user originally retrieved 
45 the page. 

A define function allows the end user to define synonyms for ti^e currently displayed page or to define 
string substitutions. Thus users may "name" often-displayed pages with identifiers tiiat are most meaningful 
for them and have such pages accessed by name at a later time. String substitutions allow users to 
abbreviate frequently used command swings. 
60 A teh function displays the definition of a specific synonym or ail the synonyms, 

A last command function causes tiie system to display the last command string that was entered by the 
user. Successive "last commands" work backwards through a sequence of previously entered commands, 
eventually returning to the newest command in a circular form. Last command has two corollary functions, 
as welL One moves through the list in the opposite direction and tiie second repeatedly retrieves the most 
55 recent command without moving through the list of saved command strings. 

A home function displays a previously designated page to be displayed and restores the end-user to a 
known state. 

A cancel function allows the user to terminate processing of the last Unction by the syst^. 

6 
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A heja function may be invoked by the user to display irrformation about how to use the system or to 
provide information pertinent to the currently displayed page. 
A reshow function redispiays the current page. 

A capture function saves the current page in a file local to the end-user terminal for offline review. 
5 An unsolicited keyword search function allows the user to enter a tenm that represents a topic covered 
within the current database. The user is presented with a menu specifying the pagesets within the database 
that cover that topic. The user may then examine the "hits" if desired through simple menu selection or the 
other navigational functions. Keyword search lets the user break out of a menu hierarchy more directly to a 
topic of interest 



Systenn/User Interftee 
Screen Management 

The display area on the end-user's tenminal is controlled by the use of multiple overlaying windows. 
The use of such windows facilitates management of the contents of the screen without losing information 
that may be important to the user, and provides for adequate and timely interactions between the user and 
the system. 

20 in the following discussion, several types of windows are described. These windows overlay the 
underlying page image when necessary and the overlayed area is always restored when the window is no 
longer needed. 

A Command line window -appears, for example, at the bottom of the screen whenever the end user 
begins t^ing something during a display mode, (Display modes will be described later in this section.) The 
as command line window is preferably wide enough to accomrrvDdate a single line of text and function key 
definitions. The command window can be made to disappear (and have tfie underlying screen restored) by 
pressing a pre-designated key. This key can be used to toggle between the command window and the 
underlying screen. If ihe key is not used to toggle between the window and the screen, the window will 
appear when the user begins a command sequence and disappear when the command has been accepted 
X for execution by the system. One of the customization options would be the placement of this command 
window, e.g., at the top of the screen or bottom of the screen, and another would be the specific toggle key. 

A Prompt window ^-allows the system to pn^mpt the end user with a short text string and obtain a 
response l>ack. This is used in conjunction with program triggers that require one or more parameters from 
the user. The prompt window appears when a user makes a nwnu choice requiring a prompt and 
35 disappears after user input has been received. 

An Acton menu window -Is a window of vahabia height (depending on the number of action items). The 
window appears on the screen when an action key is pressed and disappears when the user has selected a 
choice from Une action menu. (The action key and its use are descritsed bekrw). 

A Message window -allows the system to put up informational and/or error messages. Error messages 
40 usually appear in response to a command that could not be executed by the system for some reason (e.g., 
security violation, page not found, etc). The message window disappears when the user strikes a key to 
begin a new command sting. The message window may also be used for display of one-line messages 
sent to one end user by another end user. 

A Help text window -is used to show brief help lnfonmaik>n. The amount off information will not normally 
45 exceed a few lines. Its k>cation is also subject to custc^ization. 



Modes of Interaction 

50 There are two distinct modes of interaction which the user might be In at any time, a disoiav mode and 
an action mode. Once the user has successfully logged on the system, he is deemed to be in the display 
mode. 

In the display mode, the user can Invoke all of the informatk^n access functions which include: 
SCROLLING; MARK/RECALL; MENU CHOICE SELECTIONS and accompanying prompts, if any,; 
55 BACKUP/NEXT; RETRACE; TELL/DERNE; FIND; HOME; HELP; and CANCEL Any of these commands 
may be invoked via a function key/synonym combination on the terminal keyboard. Such function keys may 
be defined in one of three ways: 1) shorthand cursor control keys, such as those that move the cursor back 
to the beginning of the line; 2) shorthand keys for a text sting: and 3) keys for direct mapping into a 
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command. Cursor control functions never leave screen management and are thus not of particular interest 
here. Type 3) keys are routed immediately for processing as Ihey already represent the encoding of a 
command. Their functions ^e not echoed to the screen since they have no text, nor are they saved in the 
list of recent commands. 

6 Type 2) keys that map into text, farther subdivide Into two types -those that have termination characters 
and those that don't The outputs evoked by those that do are taken up for execution immediately, while the 
outputs of those that don't are displayed on the command line as If they were just typed and the end-user 
may proceed to edit the line t>efore pressing the <ENTER> key to initiate command processing. A key 
need not map Irrto an entire command, it may simply be shorthand for a common text string, with the end 

70 user supplying the rest of the command. The <CANCEL> key has the effect of aborting the execution of the 
cunrent command, if any. Function keys are defined by the user during a customtzation session, with a set 
of default definitions otherwise provided. 

During display mode, only one command may be under execution for a given user; in addition, the 
system will accept one or more type-ahead characters for pending analysis. The user does not leave ti>e 

75 display mode unless he explicitly requests the system to do so. Thus, he may view >^deotex pages and 
transaction pages without leaving the display mode. 

An action key is defined that activates an action menu window. The action key may be pressed at any 
time during the display mode. The resultant action by the system is the same, that is, it displays a window 
containing the action items that are valid on that page. For example, on a database page, the valid actions 

20 might be: a) quit the action mode; b) save the page on the personal file with a name tag; and c) enter 
message preparation. On a transaction page, the action items may be all of the above and some other 
items such as fill-in fields or activate trans action. On a message page, the action items may include 
message editing in addition to others already mentioned. 

As In the case of display mode commands (except CANCEL), an action key is effective after the current 

2S command has been executed* i.e.. It is not preemptive. 

During the action mode, the following display functions ^e suspended: RETRACE; BACKUP/NEXT; 
SCROLLING; IWARK/RECALL; TEUTDERNE; FIND; AND HOME commands. Only the CANCEL and HELP 
commands are active. The ccwnmand line window is closed during tiie acfion mode. If any of these 
functions are invoked through function keys, tfie system will: a) display an action window reminding the user 

3a of the things he can do at that point (a sort of help window); and b) give him an error message and wait for 
the user's next move. 

If the action key is pressed in the action mode, the system responds in a manner very similar to rts 
response in the display mode. It provides an action menu window for the user to select an action item 
appn^priate tor that page and at that time. For example, during the fill-in period of a transaction, tfie actions 
36 that are valid are: a) quit (same as CANCEL); b) fiil-in ( which puts tfie user back where he was); and c) 
send { which sends the filled-in fields back to the transaction program for processing). 



Application Programs Services 

40 

While information access functions as described above allow a VAN user to browse through databases 
and conduct specific searches, an information utiFrty would be Incomplete without providing the user the 
ability to act upon the Infomnatlon he/she has obtained from the utility. Accordingly, one of the major 
services provided by the VAN system is giving an end user the ability to invoke an application program in a 
46 controlled fashion. These are generically known as transactional ^^fvip^ s. Three types of such services are 
identified: program triggers; value-added page creation; and transactions. 

Program Triaoers are programs that are invoked ^d executed as a result of the user making a menu 
■selection on an index page. Program trigger identification must be imbedded in the cun-ently displayed 
page's control section. Program triggers usually require the input of one or more parameters from the user 
50 who invokes the trigger. These parameters are solicited by pr<mpt strings that axe also imbedded in the 
confrol section of the cun-ently displayed page. 

Witii Value-Added Page Creation, when a page is retrieved from a VAN database. It is possible to 
enhance the value of tiiat page to a user by "adding" current and/or specific information to that page prior 
to displaying it at the user's terminal. Such a feature Is enabled by the invocation of a program that merges 
55 the retrieved page with data that the program has derived from other sources. 

Transactions are programs tiiat can conduct an extended dialog witii the end user subsequent to their 
invocation by some overt action by the end user. (TransacQon invocations are covered in detail under 
System/User Interface above.) 
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There are many differertces between a transaction on the one hand and progrann triggers and value- 
added page creation on the other hand. Rrst, transactions are conducted in a mode where information 
access functions are suspended, while program triggers and value-added page creations are conducted in 
the information access (Lo,, display) mode. (Modes were also described in detail under System/User 
9 Interface above). Second, transactions are capable of multiple exchanges of data with an end user while the 
otfier types of program services are capable of single exchanges only. In spite of these differences, all 
application progrwris are subject to the same generic access control mechanisms as described in the 
following section. 

10 

Resource Management and Access Control Mechanisms 

Accesses to infomnation on local and non-local Videotex databases, and transactional services (both 
local and remote), are controlled through a variety of mechanisms that will now be deso^ibed. 

15 

User Validation 

Each user known to an Operations Node has a profile under the control of the ON, Access to the 
20 system is controlled by a user ID and password combination that must be provided by the end-user and 
that must match the stored values. The password, expiration date, and last password are stored in a 
separate area from the rest of the profile. Additionaffy, the password is stored in an encrypted form. 
Passwords are known only to the owner of the corresponding user ID. The System Administrator will not 
nonnally have the passwords of the users of his system. He may however change a particular password to 
29 a known value in the event the owner forgets his/her password and requests a new one. Such a scheme 
provides for maximum protection of the user's privacy while maintaining the aWftty of system personnel to 
intervene if necessary. 



30 User Groups 

One or more user groups may be defined in an Operations Node with the purpose of providing 
collective access rights to datatsase and transaction resources. Membership in a group will entitle an end- 
user to the rights associated with that group. Users may be members of not only user groups defined In the 
99 ON to which they are affiliated, but groups at other nodes as well. This alkms a user to enjoy access to 
databases that are remotely situated without explicit au^rizations at the remote ON. 



Resource Classes 

40 

In addition to users and user groups, there are two major classes of resources vwthin each Operations 
Node. These are VAN databases and VfiJ^ transactional services. These resources are defined to the 
system in a manner similar to defining users and user groups. Hie attributes of databases and transactional 
classes are different. 

45 Access to databases is controlled by a two-level check. The two levels are independent of each other. 
That is. a successful check at one level does not imply success at the other level. The first level is c^led 
the database check and the second level is called the page level check. 

ITie database level check operates as fblbws. Databases must be defined to be public or private. If a 
database is defined to be public, database checks are always successful. If a database is defined as being 

50 private, database access must be explicitly granted. This is done by inten'ogatfng an access list that is 
maintained by the system for mai database. An access list contains the identifiers of users and user groups 
that have varying types of accesses to the associated database. If the database level check is successful 
for an access requestr the page level check is then performed. This is done by matching a zone number 
associated with the page referenced by the request and a zone number occuring in the caoabiiltv Jia of the 

56 user making the access request. The zone number may be viewed as a mechanism for partitioning a 
datatrase into secure areas to which users may have selective access. A user's capability list for a datat>ase 
Is a list of zones to which he/she has access. 
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Page level checks are also carried out against access requests on public databases although no 
database level checks are required. It should t>e noted that zones and capability lists need not be defined 
for every page and for every user, in many instances, where system operators wish to run an open system, 
access control mechanisms may be disarmed by ^e absence of the controlling data structures. 
5 Transactional services may also be defined as being public or private. If a transaction is defined as 
b^ng public, it may be invoked by any and all users. If it is defined as being private, invocation is limited to 
those users (and members of user grciups) whose identifiers appear on the access list of that transaction 
resource. 

TO 

ON Configurations and Connection Mechanisms 

The architecture of the Operations Node penmlts it to be configured in a number of different ways to 
satisfy diffwent requirements (see Figure 1). A \^deatex Application Network (VAN) incorporating the 

1$ present invention generally includes a combination of distributed, semiautonomous Operations Nodes - 
(ONs), typically characterized by t) one or more affiliated users, 2) the inclusion of some form of database, 
and 3) one or more customized application programs* While each node is capable of "standalone" 
operation, that is. It can service the needs of its user population and need not be connected to any other 
node, its capabilities are considerably enhanced by its membership rn a VAN. 

20 A typical Operations Node with end-user terminals, having Videotex displays, and suitable databases 
and application programs, which may be referred to as an Establishment Ooerations Node (EON), supports 
a unique user interface through which users get controlled and secure access to a wide va'iety of 
databases stared locally and/or remotely. TTirough this node, users may also interact with a large number of 
applicatron programs distributed over the entire VAN which provide additional and specialized services to 

25 users of the node. The user interface, the mechanisms for secure access to infonr^ation, and the application 
environment supported by the ON are important features of the invention. 

An Operations Node that is dedicated to Videotex database creation and maintenance, but handles few 
or no end user terminals is known as a Database Operations Node (DON). Such an ON may be shared by a 
number of IPs to achieve economies of scale and dedicated service for IP functions- 

3D A Terminal Operations Node (TON) provides Videotex service to a set of end-users and their terminals. 
Few or no VAN datat>ases are resident at such a node* typically only a directory database. All or most 
database accesses are for remotely situated databases. The utility of such a node derives from user 
populations that generate no infonr^atiCMi bases themselves but rely on remote databases for all or most of 
their infomnation needs, A TON performs a largely terminal concenti-ation function for the VAN. 

35 A Program Operations Node (PON) is one that consists of a set of application programs that may be 
invoked by end users that are remote from the node. A PON supports no end users nor does It have any 
local \fidectex databases, only a directory database. Application programs resident at this node are 
available for use by users on other nodes. PONs may be considered to be service machines on a VAN. 
A Multi-Organizational Ooeratiops No(^e (MOON) is an ON that provides Videotex services to a 

40 collection of cn^ganlzations that cannot project a sufficientiy large user or database requirement to justify the 
cost of providing their own ONs, Oatat>ases belonging to different organizations are secured from 
unautiiorized accees tiirough the use of security mechanisms described above. 

Ccmnections to established databases on a third party system may be accessed via special i:H^otocois 
between the third party system and an Operations Node. An ON that provides access to TPDs for other 

45 ONs on tiie VAN is termed an Interface Operations Node (iON), Interface Operations Nodes may be 
impl^ented by using specialized application programs rn an otherwise normally configured Opwaticms 
Node. The specialized program implements tiie protocol between tiiird party systems and the VAN, 

A Network Operations Node (NON) may be established that is dedicated to tiie handling of access to 
other networks external to tfie VAN. 

50 An Operations Node whose database directory contains infonmation about all of the databases on the 
VAN and whose transaction directory contains attributes of alt the appiication programs within the VAN is 
termed a Svst^s Operations Node (SON). Other Operations Nodes on the VAN may query the SON for 
information regarding the existence and availability of databases and application programs. Although tiie 
SON contains valuable information, Operations Nodes on the VAN can continue to operate in the absence 

55 or failure of a SON. In addition to maintaining directory infomnation, the SON may contain statistic^ and 
usage data related to the perfonmance of otiier ONs. 
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A local cofinputer system can attach to the y/AN in a number of different ways. The preferred method of 
attachment for a database system is via direct connection as an ON. This provides full membership in the 
VAN and allows the use of all support fadlities. It requires complete adherence to the VAN architecture and 
participation in the operations of cHstributed control mechanisms. 
6 Instances may arise in which it becomes desir^le to attach certain local database systems to the VAN 
in an explicitly auxiliary manner. This can be done by means of lONs that assume responsibility for 
property representing their associated database systems in a manner consistent with the VAN architecture. 
The !ONs ttius handle all aspects of network participation. The ttiird party systems must simply adhere to 
the certain gateway protocols. This protocol is embodied in the ION communications access method. The 
10 third party systems must thus support the interconnection and presentation specific gateway interface, but 
need not change any application level code. 

A local computer system may attach directly to a particular ON as a Transaction Processor (TP) in 
support of Videotex applications resident at that ON that require extensive processing or external data input, 
manipulation, or storage. Such attachments are made on an individual basis according to the needs of local 
15 applications, and the Transaction Processors involved typically do not have a VAN appeararvce. 

A similar type of attachment can be used however to obtain a network appearance for external 
applications that are not even necessarify structured in terms of Videotex. This is accomplished by 
providing a Videotex application at an appropriate ON expressedly for the purpose of treating the external 
application as a supporting program in an attached Transaction Processor. 

20 

Architecture 

Underlying the architecture of an Operations Node is the concept of functional partitioning. Functions 
28 performed by an Operations Node are distributed among multiple processors in a manner designed a) to 
tE^e advantage of processor capafDillties, b) to utilize existing software program products^ and c) to enhance 
usability of the system. 

Rgure 2 illustrates the overall functional distribution. A host machine 20 is representative of a family of 
machines capabie of a wide range of perfomnance. An example family is the IBM 370 class of machines. 

30 The host machine 20 provides for datat>ase residency, access to remote videotex databases, store-and* 
forward messaging and for management of application programs. 

A distribution sulDsystem 21 is responsible for management of user terminal communications, caching 
of data that has already been retrieved from the host 20 and for protocol conversion from an end-user 
temiinal 23 to the host machine. An example of such a distribution subsystem processor is the IBM 

35 Series/1. The distribution sut»system 21 is attached to the host machine 20 via a high speed communication 
channel 22. An examine of such an attachment is the IBM Series/I System/370 Channel Attachment 
Feature {see Rgure 10). 

End-user tenninais 23 are intelligent programmable devices that share in tiie management of user 
sessions. The underlying philosophy in detenmining the role of these intelligent terminals is to offload as 
40 much of the system/user interface functions as possible, while remaining consistent with their capabilities 
and limitations. An example of a device that could be used as an end user terminal is the IBM Personal 
Computer (PC) (see Rgure 12). 



45 Operations Node Host Configuration 

Rgure 3 shows a sample hardware configuration and tiie Table below shows the software required to 
execute the functions of the ON host. A 370 class machine is shown but configurations using alternate 
hardware, such as tiie DEC VAX780 or Amdahl 400 series machineSi can be used with an equivalent set of 

so software components. 

The host software is divided into two pEuls: components that are part of tiie system control program - 
(SCP). such as MVS, or that are readily available in conjunction with tiie SCP; and components that 
implement specific functions described earlier in this specification. The remainder of this section wiii 
describe the components of the host that are specific to the present invention. 

56 Rrstiy, by way of example, the following Table lists the host software that can be used in conjunction 
with the hardware components shown in Rgure 3. 
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TABLE of EXAMPLE HOST SOFTWARE to IMPLEMENT 
ON FUNCTIONS on FIG. 3 HARDWARE 



10 



70 



20 



30 



40 



45 



50 



55 



1- MVS/SP1,3.X 

2- JES2 or JESS 

3- RACF 

4- DATABASE 2 (DB2) 

5- VTAM V2.X 



6- DFP/370 

7- ISPF/PDF 

8- TSO/E R2,X 

9- ON Components (See below) 



ON Host Component Descriptron 

The following is a list of components that comprise the ON Host specific software, 
-Host Control Program 
-Drstribution Subsystem Communications 
^ -Component Communtcattons 
-Process Control 



-Resource Management 
- Data Management 



-Session Management 

3s - Application Fhtigrams Management 

Figure 4 shows the interaction between tine various components. TTie Operations Node control region 30 
is the nerve center of an ON. It consists of a number of components that are discussed in detail below. 
Briefly, the control region 30 can handle requests from the distribution subsystem region 31 for infomDation 
retrieval and application program initiation. The control region also communicates with a database manage- 
ment system 32,38 for execution of complex queries on behalf of end users, tt can maintain sesslms with 
other Operations Nodes via the networking software 35. It provides data and control paths to regions 33,37 
where application programs may be executed. It communicates with Information Provider (IP) regions 34 to 
satisfy requests from IPs as well as from system administration personnel 36. 



Host Conti-ol Program 

The ON host control program ^ is responsible for invoking the appropriate component initialization 
routines. The first routine invoked is the control-data module. This module opens certain control files 
containing system configuration data. This configuration data identifies tiie command handler modules that 
make up the application layer of the host software as well as system tuning parameters. The control 
program is also responsible for loading tiie command handler modules and building a table of entry point 
addresses, called the EPATABLE, to provide gbbal accessibility to command handler services. The control- 
data module must then altocate and anchor the Host Global Data Block (see Rgure 5). The tuning 
parameters are used as input in initializing certain system control fields In the global data bio(A. Sc^ne 



12 

EXT00075671 



0 22B634 



typical tuning parameters are: 1) Identifying the current Operations Node; 2) the maximunfi number of locai 
users allowed to k)gon; 3) the maximum number of remote user sessions; 4) the minimum and maximum 
number of work agent tasks; 5) whether or not tracing Is active and statistics are to be collected: 6) the 
maximum number of retry error counts; 7) what type of caching is desired; etc. 

5 When the control-data module retums control to the host control program, the remaining system tasks 
are started. These are Port Receive Task, Port Transmit Ta^, the Operator Conf ol Task, Timer Task, and 
lastly the Work Agent Tasks. Each of these tasks perform some additional initialization functions. Once the 
$uppc»^ng subtasks are in place the control pn^gram systematically searches the EPATABLE for moduies 
that have been identified as component initialization routines. These component initialization moduies are 

10 executed sequentially, according to their positions in the tabte. 



Distribution Subsystem CommuTHcations 

15 The primary function of component or region 31 is to maintain communications with the distribution 
subsystems 21. The architecture supports a multiple port connection to the distribution processor. The host 
can support multiple distribution processors as well- The minimum port configuration between the host and 
any given distribution processor is one receive port and one transmit port, although two transmit ports are 
the norm. It has been determined that under certain hardware configurations such as shown in Rgure 3, two 

20 transmit ports make more efficient use of the channel path» whereas one receive port from the distribution 
processor is sufficient for handling traffic from ttie distribution subsystem. The architecture can support a 
maximum of 32 ports in both directions. The distribution subsystem 1/0 configuration is parameter driven 
and read in by the Port Transmit Task during its initiaflzation processing. 

There are hvo support tasks which handle all bcal communications between the host and the 

25 distribution subsystems: the Port Receive Task and the Port Transmit Task, As can be Inierred from their 
names one task handles all traffic coming from tiie disthbutk>n subsystem($) and the other all traffic to the 
subsystem(s). Having two asynchronous tasks to handle two-way communications cdkws the application to 
assume a full duplex communications channel regardless of the underiylng hardware. The absence of a 
conversational protocol, necessary in half^iupiex connections, not only mitigates the complexity of the 

30 algorithms but enhances the throughput as well. There is no need for the additional hand shying necessary 
to change modes as in typical conversational protocols, that is, request to send, dear to send, negotiate 
bind. etc. The receive protocol Is simple: the distribution ^jbsystem sends whenever it is activated and the 
host receives on demand. The undertying assumptions are ttiat me host Is inten'upt driven and can accept 
data as fast as the distribution processor can send It. The transmit protocol, on the other hand, requires 

35 somewhat more sophistication because of the likely variaice in processor speeds. The host must first 
receive an acknowledgement from tie distribution subsytem indicating that It Is ready to receive a 
subsequent data block. 

Once a data unit has been received by the host, the Port Receive Task adds to it a host header before 
placing the element or the "work unit" on the input queue. This input queue is termed the dispatcher 
40 queue. The Port Receive Task then reissues a read for the port just serviced and checks for any other ports 
requiring service. If no omer ports are active, the task waits for interrupts from all ports. 

The Port Transmit Task waits for multiple events. Event type one Is a request queued to the Port 
Transmit Task*s Input queue. Event type two is the acknowledgement issued by a distrlbutbn processor 
freeing the port for subsequent traffic. When awakened by event type one, this task obtains elements from 
45 its queue and sends them to the appropriate distrilxition sut>system. The task continues this activity until all 
queues have been exhausted. If awakened by event type two, the corresponding port is reenabled for I/O. 



Component Communications 

50 

Intercomponent communications are done through queues. All queues reside in the host control region 
and are managed by multiple consumers and producers of queued work. For example, as mentioned earlier 
ttie Port Transmit Task manages Its queue, in that it is the only consumer of this queue. Many components 
may participate in pnDducing work for this queue. Certain application level modules known as command 
55 handlers produce Port Transmit queue elements when performing the function of sending response data 
back to the originating distribution subsystem. 
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Another queue menrtioned eariier was the dispatcher (DSP) queue. The producers of work for this queue 
are afl programs that wfsh to introduce work tc the host system. Placing work on the DSP queue eventually 
resolves into the invocation of a particular command handler which handles the request. Typical producers 
of work for the DSP queue are: transactions, TSO programs. IP support programs, external network 
s software, and even hatch jobs. The sole consumes of work from the DSP queue are the Work Agent Tasks. 
These tasks will be discussed in greater detail in the Process Control section below. 

All producers and consumers of queued work units use a common queue access method software, 
referred to as the "scheduler". The gCTieric tenm "scheduler" refers to a series of modules which perfomi 
the queue operations of GET and PUT on behalf of callers txrth internal and external to the host region. 
10 There are several unique requirements of these modules that should be met, to accommodate such a wide 
variety of users. These include: 

-sensitivity to where (what address space) the caller is running; 
-the ^flity to move data across address spaces; 

T5 

-the ability to execute on behalf of both supervisor and problem programs; 
-providing levels of authorization for privileged operations; and 
20 -providing a single interface to all callers. :eul. 



Process Control 

SB 

The level of concurrent command processing is reflected by the number of executing Work Agent 
tasks. The purpose of the Work Agent is to provide an execution environment for command handler routines 
that may be invoked on behalf of some user-initiated activity. The user in this case is the end user, working 
at his or her terminal. If there are ten users logged on and only five agent tasks in the system, then tfiere 

30 can only be, at any given time, a maximum of five concurrentfy executing commands. Any additional 
requests queued to the DSP queue wouki remain on the queue until Br\ agent task was freed. The CPU - 
scheduling algorithm assumes as its model a time sharing environment. 

It is vital in any online system to present to the user an interface with some degree of consistency. The 
response time should also behave in a consistent manner, In that all users perceive a uniform response. In 

35 other words, the system should equitably distribute the CPU resource to present a reasonably consistent 
response to the end user. For example, If there are ten users that request a display of a page at roughly tiie 
same time, the system re^x^nse wouW seem extremely erratic if the request were handled serially. TTie 
first request received would be extremely fast and tiie last request would be extremely slow. However, if 
requests were processed concun-entiy, allocating CPU resource in spurts, in a round robin fashion, then no 

40 one request dominates the CPU, tiiereby allowing for a more unfform response. Taking into account the full 
set of cooperating prc>c8ssors in the VAN, user response will be effected by a number of otiier factors. The 
request may be resolved at different points, or in fact tiie request may never reach the host. The above 
example assumes all requests reached the host and were resolved at the same point 

With tiie present invention the operating system allocates CPU in task priority order. The Work Agent 

46 tasks are given a task priority by the order in which they are attached. This means that the first agent will 
always get the CPU if it has work to do, and the second agent task will run only if tiie first is idle, and so on. 
Allowing the operating system to dispatch these tasks in tiie normal fashion would also distort the user 
response, according to which agent obtained the users request and his associated priority. Because of this 
condition the host control program influences tiie operating system's dispatching algoritiim. 

so An additional function of ttie host control program Is to contix)! the allocation of CPU resource. It Is 
instructed by a tiiird task called the Timer Task, when to take tiie CPU away from tiie currently executing 
agent, to allow the next agent to execute. All three tasks, Timer, Control Program, and Work Agent, 
participate in the CPU scheduling activity. The Work Agents cateulate the elapsed execution time of every 
command. These times are used by tiie Timer Task to calculate an appropriate time slice or quantijm. The 

56 Timer Task dynamically adjusts the quantum according to shifts in the work load (it samples the recent 
history of elapsed execution times). "Rie Timer sleeps for tiie duration of a time slice. When awakened, it 
contacts the Conti-ol Program which knows tiiat it Is time for another agent. The Conti-ol Program then 
forces the Work Agent Task to relinquish control and causes the qierating system to place tiie Work Agent 
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Task at the end of the dispatcher (DSP) queue. The control program keeps track of which agent is currently 
executing. This process Is continuous. When tiie system is idte, the Timer Task sleeps for a longer 
duration, thereby decreasing the CPU overhead attributed to the scheduling activity. 

5 

Resource Management 

The ON host makes use of unique resource identification numbers that provide the basis for a 
centralized resource management metiiodology. These numbers or resource tags have been termed 

70 "Access Codes". There are three types of resource tags, each type signifying a different resource class. A 
Database Access Code or DAC identifies the database resource class. A Transaction Access Code or TAC 
identifies the transaction resource class. The third resource class is the User Class. Users are identified by 
a numb^ called the SAC or System Access Code. All access codes are obtained from ^e same pool of 
available ID numbers, making resources uniquely identifiable. 

76 Having unique numtjers identify particular resources provides for efficient management of data struc- 
tures representing resource elements. For exsmfAe, ali conM data, be it database directory elements, 
transaction directory elements, or user session management data, is anchored and manipulated from a 
common data structure and by a common resource management services routine. These resource elements 
are contained in an incore structure known as the Resource Control Table. 

20 The combination of resource tag and Operations Node ID (ON-ID: a two byte ID number uniquely 
identifying an Operations Node as a member of tiie Videotex Application Network) will uniquely identify a 
given resource on a network wide basis. For example, a SAC/ON-ID combination uniquely identifies a given 
user. This facilitates global manipMjIation of resowces throughout the network. The Resource Control Table - 
(RCT) also provides tor ON-ID qualification of resources, thereby allowing one sti-ucture to reflect all 

as resources known to a given node. If node "A" has access to the RESTAURANT database located at node 
it would have an entry in its RCT that reflects the DAC/ON-ID number kJentifying tne RESTAUR/^T 
database at node "B". 

All resource element data (User. Datafciase, and Transaction Directories) is backed by DASD. The 
Resource Control Table is built at initialization time from resource data contained in a secure dataset 
30 In the example implementation shown in Fgure 3, Resource Access Control Facility (RACF), an IBM 
program product* cited in the Table in connection with Rgure 3. may bo used as the resource access 
control tool and is also used as an access method and a r^x>sitory for host resource data. All three types 
of resources have corresponding RACF profiles. Other implemdntations may use comparable resource 
management tools witii equivalmt functions. 

35 

Data Managemmt 

The host deals primarily with Vidoetex pages as rts (Aject of data manipulation. These pages are stored 

40 in a relational table conti-olled by a relational database management system. In the example implementation 
shown in Figure 3, the fBM program product DB2. cited in the Table, may be used as tiie database 
management system. Otiier implementations can use comparable DBMS with equhraient functions. After a 
page is retrieved, it is optionally buffered in virtual memory, thereby decreasing subsequent retrieval times. 
This is called "host caching" of Videotex pages. The cache is maintained across host sessions. When the 

45 host is brought down the contents of the virtual memory cache are saved in secondary storage. 

The page manipulation software is responsible for a full range of operations: retrievals, insertions, 
deletions, and modtflcations. It is also responsible for identifying the target database, automatic initiation of 
remote page operation requests, enfc^dng datat>ase availability protocols, and enforcing user datsd^ase 
and/or page access authorization requirements. These routines take advantage of certain iDasic host 

so services In performing their required functions. For example, during a remote page retrieval, the requesting 
user's session data must be known to the remote node. Page operations software invokes user session 
management nDutines to obtain the appropriate data, if it is not already accessible, in this particular case an 
"implicit logon" would be perfomned on behalf of the remote requestor if this was his first reference to any 
database on this node. For local retrievals, this would not be necessary as the user session data is always 

€5 accessible (the user must be logged on to make a page retrieval request). 
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Page operations software, in enforcing tiie datai>as6 availability protocol, makes use of resource 
management services for obtainrng database directory information from the resource controi table, in the 
directory entry for a database, the onflne/offline status of that dat^>ase is kept. Page operations will deny 
access to an offline database. The database accessibiirty atfributes are also maintained in the directory. 

5 Databases are defined as hmng either public or private access, for both local and remote callers. If defined 
as private for a certain type caller (local or remote) page operations will call session services routines to 
check a requesting users access rights to its database (see Session Management below). 

Page operations software is also responsitde for the initiation of any post page retrieval processing 
required for a particular page. Some Vidoetex pages may require additional dynamic processing to 

to complete the page retrieved. A given page may require the initiation of a program or transaction to perform 
some unique updating or dynamic creation of pages. Page colorations must defect this condition and 
forward the retrieved page to the Start Transaction Command Handler (see Applications Programs 
Management t>elow). 

Data Management has two other subcomponents; tagged data services and dynamic page creation 

16 services. The tagged data services command h^dler is used for basic data manipulation of nonpage data 
objects. Tliese data objects have numeric labels, i.e., tags, and are stored in a variety of places. Tagged 
data may be objects that are sub-structures of existing structures or entire records on disk. For example, 
certain parts of the user directory may have been identified as a tagged sti'ucture, allowing external 
components to retrieve and/or update certain fields by tag. The users' synonym data, managed by the user 

20 interface software in the end-user terminal, is maintained as a record on a disk file. This record is a tagged 
data object and can be retrieved or updated by external callers using this common interface. External 
callers range from programs in other address spaces (System Administrator software) to dtsVlbution 
subsystem processors of remote Operations Nodes. Tagged data services, like page operations, are 
responsibie for routing requests to remote nodes, if necessary, and the subsequent response data routing. 

25 The oVtm subcomponenL dynamic page creation services, is used primarily by components that must 
communicate with tiie end user in a more dynamic fashion. This routine accepts EBCDIC text as input 
along with certain control words for defining field attributes and creates a well formed Videotex page 
complete wrth the appropriate control data necessary for handling by the distribution subsystem processor 
and end-user's terminal software. Dynamic page creation services support a wide range of options that 

30 permit: 1) designing and tailoring of a full screen of text data; 2) identifying unprotected fields for input 
processing; 3) controlling post input "type check" processing; 4) providing headings and color information; 
and 5) a NAPLPS imbed option. This service is used by certain ti-ansaction management routines, by user 
sessbn services software, and miscellaneous panel creation utilities. 

95 

Session Management 

Overall session management is accomplished In distributed fashion tiirough tlie cooperation of compo* 
nents that span processors and nodes. At the level of the user interface, session management is largely tiie 

40 responsibility of the software running in the end*user terminal. The distribution subsystem processor also 
maintains some ses^on management data on behalf of the ccH^nected end user. The host must also 
maintein session data on behalf of end users. 

Almost all processing done on the host is as a result of some end-user action. As mentioned earlier, the 
"work unit" serves as tiie basic interface between components. It also identifies the end user that is 

45 respcffisible for tiie generation of a particular piece of woric. The user's SAC and OtvHD numbers are 
contained in the work unit. Components processing in a ''user sensitive'' mode must have immediate 
access to ti^is Information. If any component requires additional user information, the SAC and ON-ID 
numbers can be used as input to a cali to resource management services (RMS). RMS locates and returns 
tile user's directory entry in the Resource Control Table, The user ID, user type, skill level, and 

sa miscellaneous conti'ol flags are contained in the directory. RMS also returns a pointer to the user's control 
block extension area. 

Session management routines are responsible for building and maintaining the extended user control 
areas. These control blocks are built at logon time by a module called user initiator/terminator (UIT) module. 
During logon pnsces^ng the user ID and password are validated and the user directory Is obtained from a 
55: secure dataset and updated in the Resource Control Table using resource management services. UIT then 
sends a copy of tiie user's directory data along with his synonym record to the appropriate distribution 
subsystem. 
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Command handlers, in coopwation with session management services, help maintain the user's 
session. Prior to the execution of any command, a preprocessor module is invoked. This module logs the 
cun-ent command executing in the conlrol block extension area. If the current request is destined for 
another node, the node history table in the extension area Is updated appropriateiy. The preprocessor 

5 retums a "preprocessing status code" to the command handler. This code will indicate one of the following: 
1) the cun-ent command has been cancelled; 2) the previous command has not been completed; or 3) 
continue nomnal fxocessing. Command handlers respond accordingly. Just after command execution, 
before sending the response data to the originating distribution subsystem, the command handler calls a 
postprocessor module. This module records statistics and retums current command status. Again, the 

fo command handler responds accordingly. For example, a completed remote page request may be discarded 
due to a cancel status. 

Other session related functions supported in the example implementation are: 

-RACF interface for logon and logoff processing; 

-RACF interface for checking user database access authority; 

-RACF interface for checking user transaction access authority; 
20 -Query for current command status; and 

-Cancel cun'ent command. 

During logoff, processing session management is responsible for: 

-Initiating "[mplicit togoff" processing at all nodes identified in the node history table; 

-Tenminating all current command execution; 
so -Purging all transient pages created during the user's session; 

-Recording final session statistics in the SMF database; and 

-Cleaning up all user session data. 

36 

Any changes to the user's directory data will be handled by a separate invocation of the tagged data 
services module initiated by the distribution subsystem. 



40 Application Programs Management 

The processing requirements for supporting application programs are: 

-multiple user support -concurrent usage; 

45 

-initiation/termrnation processing; 
-access to Videotex Services; 
5C -access to Videotex Data; 

-access to Videotex Network; and 
-access to Third Party Data. 

55 
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Transaction Application Subsystem (TAS). 

The envinonment used to support application programs Is called the Transaction Application Subsystem 
or TAS. This environment supports all three types of application programs detailed under tiie '*Appijcat»on 
5 Programs Services" heading above. 

The Transaction Application Subsystem is a Videotex subsystem that resides in its own address space- 
(s) (see Figure 8). The host control region manages one or more address spaces that constitute the 
Transaction Application Subsystem. Each such address space is called a TAS region. All TAS regions have 
identical structure as shown in Rgure 6. Multiple TAS regions may be activated by a systems operator in 
10 order to: a) support load balancing; b) support controlled testing environments; and c) provide for 
application code isolation and security^ 

In Figure 6, the "User Code" portion represents an application program that is invoked a) to add value 
to an existing VAN page* b) as a result of a menu choice selected by the end user, or c) as a result of a 
"start transaction" request from the distribution subsystem. Figure 7 illustrates the logic associated with the 
75 execution of a sample application program. 



TAS Initlafization 

20 When the host is Initialized at system startup, a "transaction directory*" is built in main storage of tiie 
host control region. The transaction directory contafns an entry for each application program known to the 
Operations Node. It contains the following information: 

-Transaction Title; 

25 

-TAG -Transaction Access Code; 
*HON -Home Operations Node ID; 
$0 -PGM -the application program to be executed: 
-STAT-loca] and external status bytes; 
- ONLN-onllne/offline indicator + flags; 

36 

-SID -subsystem ID; and 
-TASI-index into Glc^ TAS Table. 

40 An application is not available until the TAS region associated with it has t>een activated and brought 
on-line. An Operations Node providing transaction applicaf ons makes its resources available according to 
its schedule of availai^iity. \t is for this reason that the TAS regions ^e not automatically started at 
inrtiallzation time; rather a TAS region is started (or brought on-line) by the operator upon explicit 
authorization by a Systems Administrator. Once ttie region fs staled, the Transaction Subsystem Initiator 

45 (TSl) (see Figure 6) makes itself "known" to the host control region. This is called "subsystem connect" 
processing. From this point onwards, application programs associated with the TAS region become 
available for use by the end users. 

During subsystem connect processing, TSl provides the control region with all the Information required 
to access application programs associated with the TAS region. This information is used to build an entry in 

50 a table called the TAS table that contains the attributes of each of the TAS regions. 

The host control program maintains a request queue in the host region for communication between the 
TAS regions and the host. All start transaction requests are placed on the "TSM" queue where "TSM" Is 
the generic representation of input queues for TAS regions, Rgure 8 shows the data structures required to 
support TAS address spaces. 

55 
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hlow Applicatton ^ograms are bivokad 

The distribution subsystem requests that a transaction session be started on behalf of a given user by 
constructing a request block and passing that request to the host (see Rgure 9). The request activates the 

5 Start Transaction Session command handler, which interacts with other system services in establishing the 
transaction session. This command handler is responsible for: forwarding "remote" start requests to target 
nodes; initiating Implicit logons for remote users (if not already logged on); obtatnrng the transaction 
directory entry via a call to RMS; initiating "access check" processing, if required; and passing the start 
request to the appropriate TAS region. The transaction directory entry will indicate whether or not this 

10 transaction is cun^ently available, and identify tiie accessibility status of the transaction. Transactions 
defined as "private" will require access checks. The transaction directory also contains an index into the 
TAS table, identifying the owning TAS region. 

The Transaction Subsystem Initiator after having completed subsystem connect processing, simply 
waits for work. When a request Is placed on its queue in tiie host region, the scheduler wakes up TSI using 

fs infbrmatfon stored in the TAS table, whereby TSI issues a QETQ request to the host region. Once the 
queue element has been obtained TSI locates a free Work Agent request block (see Rgure 6) and updates 
it with the passed information (a composite of the tr^sactlon directory entry and some fields from the 
invoking user's directory entry), T^ien, based on the environment required by the transaction, It performs the 
appropriate Work Agent attach processing. 

ao When the Work Agent has been attached. TSI solicits ^e host for more work. When the request queue 
has been thus depleted, the initiator waits on multiple events. These are the completion events of one or 
more active Work Agents and the event caused by a host-to-TAS "work pending" signal. When a Work 
Agent has completed its work it is detached by TSL 

Wien a Transaction Work Agent (TWAG) is activated by TSI. it searches the Work Agent request 

25 blocks for the one it has been assigned. It then claims tfie request block and sets up tiie execution 
environment. The TWAG also establishes a recovery enirtronment, loads tiie transaction program (User 
Code), and transfers control to the transaction. Transaction Interface Routines (TIFls) are invoked by user 
code as and when needed to perform various display formatting functions, end user communication 
functions and file access functions (see Figure 7). 

30 Because TIRs are shared by potentially many application programs whrch in turn may be invoked by 
many end users, each TIR must use the Transaction Access Code (TAG) and ON-ID of tfie application 
program (available in the request block of ttie TWAG) as well as ti>e System Access Code (SAC) and ON-ID 
of ttie end user in making service calls to the host control region. Examples of such service calls are access 
checks on host resources, and sending and receiving data from the end user's terminals. TIRs are also 

36 responsible for temninating an interactive session witii the end user upon request by the application 
program. 



Operations Node Distribution Subsystem Hardware Environment 

40 

Figure 10 presents a sample hardware environment that may be used to implement the distribution 
subsystem. This sample hardware uses the rBM Series/1 as the processor. Other sample processt^ tiiat 
may be used are the DEC PDP 11/70. tf^e Data General Eclipse/1, and equivalents. The number of 
terminals supportable will vary depending on the exact configuration. The example hardware can support up 
45 10 64 end-user terminals. 

The hardware components that may be varied to obtain different levels of perfonmance are: 

1) a 4966 processor with built-in 30MB disk and 1MB real storage as the built-in disk provides the 
most coi^-effective configuration; 

2) one diskette drive, any model, necessary to install software and for diagnostics: and 

so 3) a 4S78 or 4980 temninal for an operator, for diagnostic execution, and for miscellaneous use. 



Distribution Subsystem Sofhware Environment 

55 The distribution subsystem software architecture has many tjasic properties fundamental to its organiza- 
tion. These are as follows: 

-Multitasked. This feature is provided by the underiying system control program. For example, for tiie 
sample hardware shown, the prefen'ed contirol program is tiie IBM Event Driven Executive. Alternate control 
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programs include the IBM Real Time Programming System (RPS). 

-Queue driven. Communication among the tasks, particufarly with regard to requesting service from one 
task by another^ takes place using queues. Each task has an Input request RFO queue that it checks for 
work. The queue contains request parameters and the processing normally results in the production of a 

5 request on another -task's queue. (In the simple case, the request is the response infomnationO 

-Memory constrained. The architecture reflects the fact that real memory available on the system may limit 
the capacity and flexibility to support a large population of terminals, ;Ii-Resident. The programs reside in 
main storage at all times, except for a few utility programs. There Is no dynamic loading or unloading using 
auxiliary storage. 

70 -Interrupt driven I/O. No polling. 

-Partially re-OTtrant. Some of tie modules are re-entrant. Others are serially reusable by virtue of their 
handling only one request at a time as extracted from their input queues. 

-Dedicated system. The software acts as if there is no contention for hardware resources from other 
applications. 

75 Hgure 11 shows the overall organization of the components that comprise the distribution subsystem 
software. Functionality spreads across many different programs, all competing for the CPU and other 
resources at once. There is no "main" program in control. The control program arbitrates among ttie 
competitors using its algorithms in most cases, with some lower level control within a specific module done 
by the module itsetf. A description of data fiow through the modules will be discussed later, but first a brief 
20 description of the functional elements pictured in Figure 1 1 follows. 

The I/O Controller Subsystem (IOCS) 110 provides the "link layer" protocol support for communication 
vwth the user terminals over asynchronous iocal or dial-in lines. This Includes interrupt handling, error 
recovery, writing, reading and device control. 

The Terminal Handlers 111 provide the "session layer" protocol for communication with the user 
as terminals. Some communication with the tenminai may be handled completely by this layer and below, but 
most of it involves the Service Manager 112 at the application level. Adequate implementation may be 
accomplished with only one Terminal Handler. 

The Service Manager 112 is effectively the "main program," as user actions eventually percolate up to 
this, the "application layer." It processes commands from the user, sending requests to the page buffer 
30 manager, the channel attach support, the terminal handlers, and so on. 

The Host Communication components. Ghainel Attach Support 114 and Channel Attach Progr^ 115 
control the communication channel (22) (see Rgure 2) between the Host (20) and the distribution 
subsystem (21), Other components interact with Ihem through a set of macros and data buffers. 

The Host Command Support component 116 routes Host commands. Most interaction with the Host is 
35 the result of user action. However, the Host initiates some functions supported by the distribution 
subsystem. Any command generated by the Host (as opposed to responses for commands from the 
distribution subsystem) Is routed through this task for processing. 

The Page Buffer Manager 113 maintains a collection of videotex pages on local disk for quick retrieval 
without involving the Host. Requests to retrieve a page go through here first to see if the page has been 
40 saved. Pages sent from the Host are written to tiie disk by ^is component 

The Performance Monitor 117 is a task tiiat periodically executes and samples syst^ performance 
statistics, writing the snapshot buffers to disk for later analysis. 

The Activity Log 118 is a task that controls the tog of activity wltiiin the Service Manager, periodically 
writing it to disk for later analysis. 
46 The Tr^ Program 119 is an optional program that interacts with the IOCS through LCBs to control 
tracing on the terminal lines and record the results. 

The Operator Program 120 is a program that mns from a locally attached terminal that provides control 
over ON parameters and operation. It also includes display functions to monitor system operation. This 
program is not required for the ON to run. 
50 The Initialization Program 121 initializes ^e subsystem software by allocating storage, loading pro* 
grams, starting up ttie I/O devices and so on, before exiting. It does not exist during normal operation. 
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Sample System Row 

Given the overview in Figure 11, the following is an example of how control and data ftow through the 
system for a sample operation. Let the request be a page retrieval as initiated by the user. Assume the 
6 page does not exist in the page buffer 1 13, 

command data from terminal 
Interrupt handler — 

terminal IOCS (110) -* terminal handler (ill) 
10 service manager (l 12) page buffer (113)** 

channel attach (1 14^116) output task I/O to Host 

Host writes response — 

channel attach (114.115) input task 

page buffer (113)-* service manager (1 12) 
T6 terminal handler (111)-* 

IOCS (110)-* write data to temiinal 

Acknowledgements and error recovery are riot shown* and neither are peripheral functions such as the 

performance monitor and the channel attach timer task. 
In further detail, the operating steps are as follows. 
20 1. The interrupt handler gets one byte at a time from the terminal line and passes them on to the 

IOCS 110. The IOCS assembles them into a tink-level packet and removes the packetizing data, producing 

a data stream for higher level processing, 

2, When the IOCS 110 has sufficient data. It generates a queue element and sends it to the terminal 

handler (1 1 1) associated with that terminal. 
25 3. The terminal handler 111 checks for session layer information and routes the data on to the 

service manager (112) user task for this line. 

4. The service manager 112 decodes the request and does the processing that it can. Eventually a 

page retrieval command is built for sending to the Host But first, the request goes to the page buffer 

manager 113. 

30 5. The manager 1 13 determines that the relevant page is not In the buffer and routes the request on 

to the channel attach (1 14,1 1 5} output task. 

6. The output task writes the request to the Host. 

7. The Host response comes back through the input task. The task takes the queue element on the 
pending response list and fills It in with pointers to the input data. Since the task can recognize a page 

35 retrieval response, it mutes the response to the page buffer manager 113 Instead of the service manager 
112, 

8. The page buffer manager 113 inserts the page into the buffer and then sends the data to the 
service manager 112. htol© that the page buffer manager 113 is noj operating in parallel with the serwce 
manager processing of the same data. The page goes into the buffer (113) before it even gets to the 

40 service manager 112. The main reasons for the serial processing here are: a) the time spent by the page 
buffer 113 rs not substantial compared to all the other components in the path, and b) since the page buffer 
manager 113 and servfce manager 112 woukJ share the same physk^ data, added complexity woukJ be 
required to make sure the service manager 112 did not release the storage before the page buffer 113 
finished. This seriaiization can cleariy be removed if necessary. 

45 9. The service manager 112 packages tf>e data for shipment to the terminal, using the af^ilcation 

protocols. It sends the data In the buffer (113) to the terminal handler 111. 

10, The final stages packetize and write the data, and process the acknowledgment The tricky part 
here involves writing part of the page and getting acknowledgments al<x*g the way. The distribution 
subsystem does not normally have enough memory to make sure that all the lines can keep a page in 

60 logical storage at once. Thus, swapping In of one segment m. a time per line during its write to the terminal 
is done with acknowledgement after each segment (multiple packets). The Intermediate stages are required 
only if a transfer exceeds one storage segment. 
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Operations Node End-User Tenriinal Hardware Environment 

'An example of a hardware configuration for the end-user interface is shown in Rgure 12. The 
components are generally as follows. 

-A computer, such as a PC, with at least 256KB of memory is required. 

-A computer keyboard for inputting commands and data Is required. 

10 -A Diskette with drive is required but a Hard Disk is optional. Some services may require write access to 
file. 

*A color monitor is required for a Videotex environment, A monochrome monitor may be used to support a 
non-videotex environment 

T5 

•Required additional hardware are a graphics adapter and a modem if the system is not locally attached. 



20 End User Terminal Software Environment 

The major components of the PC terminal software will now be described with general reference to 
Figure 13. 

Firstly, Supervisor and Shared Services Interface routines are provided for access to the operating 
as systmi services for intertask communication, memory management, and timer control (they are not 
indicated in the Rgure). The I/O Controller Subsystem 110 provides the link layer communication to the 
processor (Series/1). The ICXJS 110 implements the packet transfer mechanism over asynchronous data 
lines, with enx»r recovery. It consists of two tasks, one for data writes and control operations, and the other 
for processing input data from the communications tine. The IOCS deals with the session layer above it. 
30 The Session Layer 130 provides the session layer protocol, primarily for session initiation and 
termination and for being the pipe between the application and data link layers. It Is a single task that listens 
for requests and data signals from its two neighixiring layers. 

The Screen Manager 131 is a task to manage the screen and the keyboard. It maps keystrokes into 
their definitions and controls such ftinctions as cursor control and echo, in addition, ttie task manages 
35 windows for user input and program ou^ut. 

The Application Manager 132 is the main portion of the Videotex subsystem. This task communicates 
wtm the session layer 130. the screen manager 131, and the NAPLPS decoder 133 in processing user 
requests from the keyboard and data sent from the processor (Series/1 Many of the Videotex functions for 
database navigation and data retrieval are harvdied completely by the application manager 132« such as 
40 scrolling, selecting menu choices, reckling previously seen infbmnalion, and synonyms. Most functions 
eventually result in a Videotex page retrieval being initiated through the session layer 130. Thus a typical 
scenario is as Allows: a) the user enters a command via the keybo^d; b) ttie screen manager 131 sends a 
signal to the application manager 132 that a command has been entered; c) the application manager 132 
decodes the command and figures out what page or other data is required from the Host; d) the application 
45 manager 132 formats and sends a command to the Host via the session (130) and lower layers; e) the Host 
response returns via session layer 130 and is processed by the afi^^f^cation manager 132. 

An additional application manager fonction is to manage transaction input by defining input 
fieldsAftfindows through the screen manager 131 and processing tfie user input data. 

Custom izers may be used, that is, standalone programs that the user may run to customize his 
50 keyboard definition and to customize application parameters such as the amount of memory to allocate for 
stacks (they are not indicated in the Figure). 

The NAPLPS decoder 133 converts a NAPLPS data stream into the gr^hic commands. 
Graphics Support 134 software converts graphics primitives into actual images on the monitor. 

55 
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The two remaining figures. Figures 14 and 15, show the end-user terminal architecture In further detail. 
Firstly, the i/0 Receiver task 140 receives input data and signals whenever output data has completed, tt 
packages input data for shipment to Session Layer tasks 130 and ultimately to the application. The Session 
Layer asks the I/O Service Manager task 112a to mite data to the communications Nne. The Intenupt 

5 Handler 141 processes the bwest level signals from the communications line hardware, and the Timers 142 
limit the amount of ttme to wait for certain events before Initiating error recovery. 

An example of the operation of the keyboard processing architecture shown in Fgure 15 is as follows. 
The user input signals anive via the Inten'upt Handler 141a and the control program. The Screen Manager 
131 uses a definitions table 150 to interpret keystrokes and control their processing once an entire 

10 command is received. A Window Manager 151 interacts witti tfie k>wer level graphics support on the 
monitor. The individual command handlers 152 are activated based on the specific command 153 and they 
manipulate user data 154 and messages 155. communicating with the Host via the IOCS 110 as needed. 
The process is repeated with the next user input- 
It will accordingly be seen that an architechjre for and the implementation of an Information utility has 

rs been described for accessing infomnation and executing fransactions on an interactive basis between 
Videotex databases and individual end user terminals in a novel and advantageous fbnn and manner. 



Claims 

Having thus described our Invention, what we claim as new and desire to secure by Letters Patent is: 
1, A system for enabling users thereof to electrmically access a wide range of infonnation, and 
including a capability for Interuser messaging and executing of transactions, comprising: 
a) temilnal means for displaying graphical and textual infonnation to a user; 
25 b) a first operational node connected to sakJ temntnal means and comprising: 

1) first database means for provkJing graphical and textu^ information; and 

2) first a|:^licatk>n program mesffis for exchanging messages and executing transactions on behalf 
of sakJ user: and 

3) a second operational node comprising second database means and second application program 
30 means for respectively providing graphical textual information, and exc^ging messages and execut- 
ing transactions; and 

d) means for enabling said terminal means to access said graphical and textual information from 
said first and second database means and to exchange messages oxl execute fransactions with said 
second operational node, through said first node means. 
35 2, A system as in claim 1 further comprising a third operational node connected to said first operational 
node and comprising third database means and third application program means for providing information 
about said first and second datat>ase means and saud first and second application program means to said 
temitnal means, 

3. A system as in claim 1 wherein said enabling means comprises networic means for operationally 
40 connecting said first and second operational nodes, 

4. A system as in claim 3 ^rther comprising third database means for supplying graphical and textual 
information and operational node means ior connecting said third database means to said network means 
for accessing by said first and second operational nodes. 

5. A system as in claim 3 further comprising a plurality of twmtnal means for displaying graphical and 
45 textual information and operational node means for connecting said plurality of temrirnal means to said 

network means. 

e. A system as in ciaim 3 further comprising directory database means fbr provkling a directory of 
available graphical and textual Infonmation on said network means arxf operatiCHnal node means for 
connecting said directory database means to said network means. 
50 7. A system as in claim 3 wherein said first operational node further comprises means for connecting 
mother tenminal means and another database means to said network means. 

8, A system as in claim 3 further comprising operational node means for operationally connecting said 
netw<vk means to a dat^>ase outside of said network means. 

9- A system as in claim 3 further comprising operational node means for operationally connecting said 
56 network means to another network means. 

10. A system as in claim 3 further comprising operational node means, comprising a plurality of 
application programs and connected to said networi< means, for exchanging messages with and executing 
transactions witii said terminal means tiirough said first operational node. 
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11. A system as rn claim 3 wherein said first operational node furtiier comprrses means for identifying 
said user, said identifying means comprising an operational-node-unique identifier and a system access 
code, the combination of which Is unique to said network means. 

12. A system as in claim 3 wherein said first database means comprises means for identifying said first 
6 database, said identifying means comprising an operational-node -unique identifier and a database access 

code, the combination of which Is unique to said network means. 

13. A system as in claim 1 wherein said Urst database means comprises a database directory of said 
first (peraflonal node. 

14. A system as in claim 1 wherein said first database means comprises page means for providing 
70 graphical and textual infonmation and comprising a variable length electronic data structure consisting of 

con^ol information and displayable data 

15. A system as in claim 14 wherern said first database means further comprises pageset means for 
org^izing said page means in a scroll sequence. 

16. A system as in cf^m 15 further comprising scroll means for accessing said page means in their 
75 sequence order within a pageset means for display on said terminal means. 

17. A system as in claim 14 further comprising exit path means for exiting from a display of said page 
means on said tenminal means. 

18. A system as in claim 14 further comprising find means for accessing said page means directly from 
within said database means. 

20 19. A system as In claim 14 further comprising mark means for marking said page means being 
displayed on said terminal means for later access. 

20. A system as in claim 14 further comprising recall means for recalling said page means that was 
marked for lat^ access. 

21. A system as in claim 14 further comprising defining means for identifying said page means being 
25 displayed by a synonym for later access. 

22. A system as in claim 14 wherein said first application program means comprises means for adding 
infCM^mation to said page means after being selected for and prior to display. 

23. A system as in claim 14 further comprising first check means for accessing said first database 
means and second ciieck means for accessing said page means. 

30 24, A system as in claim 1 wherein said first application program means comprises means for invoking 
and executing a program in response to a user selection through said terminal means. 

25. A system as in claim 1 wherein said first application program means comprises means for 
exchanging infomiation between said terminal means and an operational node. 

26. A system as in claim 1 wherein said first operational node comprises host means for accessing data 
3S and distribution subsystem means for caching said data. 

27. A system as in claim 26 wherein said host means comprises a receive port and a transmit port and 
further comprising means for handling all communicafions to said receive port from said disfribution system 
means and means for handling all communications from said transmit port to said distribution system 
means. 

40 28. A method for establishing a system for electronically accessing InfCH'mation. exchanging messages, 
and executing transactions through an enduser terminal at an operational node, compri^ng the steps of: 

a) providing a first dat^^ase for supplying graphical and textual infomnation; 

b} providing sad terminal with a display for graphical and textual information; 

c) constnjcting a first operational node connected to and including said first database and said 
46 terminal; 

d} providing a second database for supplying graphical and textual information; 

e) constructing a second operational node including said second database and connected to said first 
operational node for supplying graphical and textual Infomiation to said tenninal tfirough said first 
operation^ node; and 

50 f) providing a first application program at said first operational node and a second application 

program at said second operational node for controlling the transferring of information, exchanging of 
messages, and executing of transactions between said terminal and said second operational node through 
said first operational node, 

29. A method as in claim 28 further comprising the step of connecting a third operational node to said 
55 first operational node Including a third database and a third application program for providing Information 

about said first and second databases and saJd first and second application programs to said terminal, 

30, A method as in claim 28 comprising the further step of operationally connecting said first and 
second operational nodes to a network of operational nodes. 
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31. A method as in claim 28 comprising the further step of providing a third database for suppfying 
graphical and textual information and an operational node for connecting said third database to said networic 
for accessing by said first and second operattona! nodes. 

32. A method as in claim 28 comprising the further step of providing a plurality of terminals for 
s displaying graphical and textual information and an operational node for connecting said plurality of 

terminals io said network. 

33. A method as in claim 28 further comprising the step of providing pages of graphical and textual 
information rn the fomn of variable lengtti electronic data structures consisting of control information and 
displayable data to said first datai>ase. 

10 34. A mettiod as in claim 33 comprising the said first database means further step of organizing said 
pages Into a pageset in a scroll sequence. 

35, A method as in claim 28 comprising the further step of providing said first operational node with a 
host for accessing data and a distribution subsystem for caching said data. 

36, A method as in claim 28 comprising the further steps of providing said host with a receive port and 
75 a transmit port and handling all oommunicetions to said reoerve port from said distribution system and 

handling all communicatiCNis from said transmit port to said distribution system. 
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